The wireless telecommunications market has experienced rapid growth over the past few years and that growth is projected to generally continue for the foreseeable future. Increasingly, wireless devices are becoming more sophisticated and capable of supporting wireless applications. The growth in the sales of wireless devices is fuelling the simultaneous growth for a wide range of wireless services for wireless application ready devices such as banking, shopping, and e-mailing and, particularly, new location-based services.
A challenge exists for those who are building wireless services as the services must be reliable and scalable and meet user demands. At first, building such services might appear to be a very simple task that a service provider alone may try to tackle by developing a complete solution from one end to the other. However, as wireless services grow in size, more cost effective and reliable solutions will be necessary.
Message-oriented middleware (MOM), for example, a message queuing (MQ) system, provides asynchronous message transfer services between applications. Such systems enable applications to exchange information in a time independent fashion, without requiring that the source and destination applications be concurrently active.
Various software companies have developed commercial MOM products: the MQSeries® message queuing system from International Business Machines Corporation is one such product developed for heterogeneous any-to-any connectivity from desktop to mainframe. A comprehensive family of application programming interfaces (APIs) are designed to make coding for any messaging task straightforward, enabling system integrators to focus on the business logic rather than on operating system specific details. Message and transference integrity is another key feature of MQSeries, as a once-only message delivery is always assured—even when the underlying applications or networks fail.
In a typical MOM integration scenario, two or more applications exchange information in an asynchronous manner via a MQ system network of one or more nodes. The applications communicate by putting and getting messages from queues. Messages are stored at intermediate queues in the network until the MQ system is able to process them. Messages are routed toward the destination application and held in a final queue until the destination application retrieves the message.
A queue at a node is managed by a component known as a queue manager. The queue manager provides the necessary services to applications that use the queue (e.g. putting and getting) and communicates with other queue managers to route messages to correct queues. In order to accommodate the needs of critical business applications, MQSeries provides support for transactional messaging, secure messaging, triggering mechanisms and thin clients. MQ systems are flexible and versatile, permitting a single queue to work with several applications. Operation of the MQ system network is transparent to the source and destination application as each need only be concerned with interfacing to a high-level API. In addition to providing an API that may be particular to a specific MQ system, a MQ system may provide APIs in accordance with the Java™ Message Service (JMS) specification of Sun Microsystems, Inc., conveniently extending the MQ system to Java-based applications and components.
Further flexibility and versatility is provided in the MQSeries product line through MQSeries Integrator (version 1.1). Built on top of the basic MQSeries messaging framework, MQSeries Integrator is a powerful information broker that selects and distributes information to the applications, databases and users that need it. MQSeries Integrator builds new or extends existing messaging solutions, enabling customized message processing. MQSeries Integrator provides both the MQSeries messaging layer and a message brokering hub for processing, transforming and distributing messages, and, optionally, combining these features with a publish/subscribe function. By enabling customized message routing and transformation of message content, MQSeries Integrator separates business logic from application logic and/or data logic.
A key concept used in MQSeries Integrator is that of a message flow. A message flow is a visual representation, like a wire diagram, in a graphical development environment of how a message is transformed while “flowing” between queues. Message Brokers (brokers) act as a way station, or a hub, for messages passing between MQSeries applications. Once messages have reached the broker, they can then be processed in accordance with the configuration of the broker and the contents of the message. Within the broker, individual functions are assigned to a notional collection of interconnected nodes (e.g. dynamic linked libraries (DLLS) called from the broker's execution environment), where the processing and transformation activities can take place as required. In addition to basic nodes that MQSeries Integrator provides to process, transform or distribute messages, customized nodes may be provisioned to further enhance message flow capabilities. An exemplary message flow scenario in accordance with the prior art is illustrated in FIG. 1.
One additional feature of MQSeries Integrator and other MOM of particular importance is publish/subscribe functionality. A publish/subscribe system is responsible for distributing message-based information from publisher applications to subscriber applications by means of selected topics. In a publish/subscribe system, a publisher is a supplier of information defined by a topic. A subscriber is a receiver of information on topics of interest and may also be a forwarder of the information to other interested subscribers. A topic is the subject of the information that is contained in a message and a stream is a grouping of related topics. Streams are useful for providing access control to topics. Finally, a broker is a service that controls and routes the messages from the publishers to the subscribers.
The publish/subscribe paradigm further enables the de-coupling of applications that provide information from applications that consume information. For publisher applications, information can be made available without needing to know who has requested or will request it and, therefore, to whom to send the information. For subscriber applications, a publish/subscribe system's functionality is greatly enhanced by increasing the refinement of the selection criteria. There may be many messages published for a topic that are not desired by particular subscribers, even when the topic matches the subscriber's general criteria. MQSeries Integrator allows content-based subscription and improves the refinement of the selection of the messages to be sent to subscribers, so that a more selective and therefore more efficient method of distributing information is provided.
A simple publish/subscribe system 10 in accordance with the prior art is illustrated in FIG. 2. A set of publisher applications (publishers) (collectively, 12) provide information in data messages according to topics to one or more subscriber applications (subscribers) (collectively, 14) that have expressed their interest in the topics. Between publishers 12 and subscribers 14, there is a publish/subscribe data processing broker network having a plurality of broker computer systems 16 (brokers) communicating with each other via the network that manage and route the messages from publishers 12 to subscribers 14. It is important to observe that more than one broker can coexist in system 10, enabling scalability through the forwarding of messages to each other.
The relationships between publishers 12, subscribers 14 and brokers 16 of system 10 in FIG. 2 may be summarized as follows:
Publisher and Broker
                Publishers can register to publish information to one of the brokers on a specific topic;        Publishers can send messages to a broker;        Publishers can request the deletion of messages retained by the brokers; and        Publishers can de-register with a broker.Subscriber and Broker        Subscribers can register with one of the brokers for one or more topics of interest to the subscribers;        Brokers can send the information to each subscriber based on the registrations; and        Subscribers can de-register with the brokers.Broker and Broker        Brokers can exchange subscription registrations and de-registrations;        Brokers can exchange publications and delete requests; and        Brokers can exchange information about themselves.        
As noted MOM facilitates messaging among applications. One application area experiencing major change is the area of wireless applications. The Wireless Application Protocol (WAP) specifies an application framework and a set of network protocols for providing Internet communications and advanced telephony services on a wide range of wireless devices such as digital mobile phones, pagers, personal data assistants and other wireless terminals. The WAP specification attempts to extend and re-use existing mobile networking technologies as well as Internet technologies. The motivation behind WAP is to enable devices with limited resources (power, CPU, memory, display size, etc.) that operate in wireless data networks with limited capabilities (bandwidth, latency, connection stability, availability) to access the World Wide Web.
According to the classical World Wide Web client/server model, a client uses a web browser to initiate a request, or pull for content, to a web server. The web server responds to the client request by sending the requested content in a response. WAP accommodates the pull model, extending the web architecture by adding telephony support with Wireless Telephony Access (WTA). Moreover, WAP enables a “push” model where a server can proactively send content to the client.
In a typical WAP configuration, illustrated in FIG. 3, an additional layer is deployed between client and web server for facilitating communication of web information wirelessly. A WAP Proxy Gateway provides the extra layer and is responsible for translating requests from a WAP protocol stack to an HTTP protocol stack and vice-versa. The WAP Proxy Gateway is also useful for encoding and translating content into more compact formats suitable for wireless networks. Recent WAP protocols do not require a WAP Proxy Gateway in all circumstances since client and web server communications may be conducted using HTTP/1.1 supporting wireless communications. However, a WAP Proxy Gateway can optimize the communication process and may offer mobile service enhancements such as privacy, location and presence based services. A WAP Proxy Gateway is necessary, however, to offer push functionality.
A push operation between a Push Initiator (PI) and WAP client is performed by permitting PI to transmit push content and delivery control instructions to a WAP Push Proxy Gateway (PPG) which then delivers the push content to the WAP client according to the delivery instructions. PI may be configured as an application running on an ordinary web server. PI and PPG may be configured as separate entities or co-located. Co-location supports PPG operator services, large service providers, and scenarios requiring transport level end-to-end security among other requirements or benefits.
PI communicates with PPG using a protocol known as Push Access Protocol (PAP). To deliver push content to the client, PPG uses a protocol known as Push Over-The-Air (OTA) Protocol. PAP is based on standard Internet protocols; XML is used to express the delivery instructions, and the push content can be any MIME (multipurpose Internet mail extensions) media type. These standards help make WAP push flexible and extensible.
PPG does most of the work for push communications since it is responsible for routing the push content to the client. PPG has the ability to perform authentication and access control, address resolution, protocol conversion, binary encoding, and content filtering among other tasks. It may query for a specific wireless client's capabilities and provide the results to an inquiring PI, in order to aid in creating better formatted content. A PPG can also perform broadcasting or multicasting of messages.
PAP supports the following operations:
                Push Submission (PI to PPG)        Push Notification (PPG to PI)        Push Cancellation (PI to PPG)        Status Query (PI to PPG)        Client Capabilities Query (PI to PPG)        
PAP can be tunneled through HTTP for compatibility with existing Internet infrastructure.
OTA is responsible for transporting the data from PPG to the wireless client using a WAP Session Protocol (WSP) in either a connection oriented or connection-less manner.
Push message content is divided into several parts and contains control information for the PPG. Control information includes recipient address(es), delivery time constraints, Quality of Service (QoS) information, notification requests, etc.
In operation, PPG acknowledges successful or reports unsuccessful parsing of the control information to the originating PI. Debug information about the push content itself may optionally be reported. Once the content has been accepted for delivery, PPG looks for the correct client and delivers the content to that client. Push content timeout parameters may be used to limit PPG delivery attempts. Such timeouts may be set by the PI and/or policies of the PPG operator.
Upon request of the PI, the PPG may also send a notification when the final status of the push submission (delivered, cancelled, expired, etc.) has been determined. As discussed previously with respect to message queuing systems, push services between PI and PPG are asynchronous from PI's point of view as PI is not required to wait on-line for PPG to complete its delivery.
The WAP push framework permits any MIME media type to be delivered between PI and client. Additional media types have been defined by the WAP standard to add capabilities not already provided by existing MIME types. In particular, the Service Indication (SI) MIME media type provides the ability to send notifications to end-users in an asynchronous manner. Such notifications may, for example, relate to new e-mails, changes in stock price, news headlines, advertising, reminders of low prepaid balance, etc.
In its most basic form, an SI contains a short message and a URI (uniform resource identifier) indicating a service. The message is presented to the client end-user upon reception, and the user is given the choice to either initiate the service indicated by the URI immediately, or postpone it for later handling. If the SI is postponed, it is stored by the client device. SI is presently the only mandatory WAP push framework media type.
The SI specification provides various mechanisms for improving the end user experience such as: User-Intrusiveness levels, Deletion of invalid SIs, Replacement of expired SIs, Handling for out of order delivery, and Expiration of SIs.
An example of how Service Indication can be used is user notification for new emails. Typically, a wireless email service provider provides a WML web site to allow a user to navigate through the user's email program. When a new email arrives at the web server, preferably, the user is notified. A service indication is sent to the user, such as a text message (e.g. “You have 1 new email”) and a URI, that allows the user to directly go to the WML site to browse the new email.
In some cases it is not suitable to wait for a client to respond to the service indication. For such cases, it is more suitable that the client device loads the service that is indicated by the push message without requiring a user input. Service Loading (“SL”) is an additional MIME media type that conveys an URI that points to some content to be loaded by the client without end-user confirmation. SL also includes an instruction whether the content should be executed and/or rendered or placed in the client cache. If the content should be executed and/or rendered, PI can control the level of user-intrusiveness.
For example, SL can be used when a user with a prepaid wireless telephony service subscription is coming to the end of their prepaid funds during a phone call. In such a scenario, it may be more appropriate to have the wireless device load the service that is used for allowing the user to add more funds to the prepaid subscription than to disconnect the call. Once the service is loaded and the appropriate information is transferred the user can select the appropriate action, such as by pressing a button. If Service Indication is used instead, the user is required to first accept the service, load it and then proceed to add more funds.
Wireless messaging applications may be supported under alternate protocols other than WAP. For example, NTT DoCoMo, Inc. of Japan has commercialized i-mode™ wireless services providing wireless e-mail, web browsing, message services and other features for wireless telephone devices using packet data transmission. FIG. 4 illustrates a block diagram of the i-mode model. While there are many similarities between WAP and the protocol of current i-mode services, one difference is in the area of web page description languages. WAP specifies WML while i-mode presently uses a compact HTML (cHTML) similar to ordinary HTML based Internet web sites. NTT DoCoMo's i-mode also provides support for wireless push messages.
To provide new wireless services or to extend legacy services to a wireless environment, cost-effective, reliable and scalable solutions that will meet the user demands are required.